This invention relates generally to standard request-response protocols such as the HyperText Transport Protocol (HTTP), and more specifically to providing for depth-related requests without root information or actions according to such standard request-response protocols.
The HyperText Transport Protocol (HTTP) has emerged as the standard mechanism by which information is transported over TCP/IP (Transmission Control Protocol/Internet Protocol) compatible networks, such as the Internet, intranets, and extranets. HTTP is more specifically an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol that can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers. It is referred to as a transport protocol, since information is transported according to its specifications, and is also referred to as a request-response protocol, since information is exchanged by a client making a request of a server, which generates a response thereto. HTTP as referred to herein refers generally to any standard of HTTP, and specifically to HTTP/1.1, as described in the HTTP Working Group Internet Draft dated Nov. 18, 1998, prepared by Fielding, et al., and available on the web site htt://www.w3.org.
A common use of HTTP is the transport of information formatted according to a markup language. For example, a popular application of the Internet is the browsing of world-wide-web pages thereof. In such instances, typically the information retrieved is in HyperText Markup Language (HTML) format, as transported according to HTTP. However, other standard markup languages are emerging. One such markup language is eXtensible Markup Language (XML). XML describes a class of data objects that are referred to as XML documents, and partially describes the behavior of computer programs that process them. A primary difference between HTML and XML is that within the former, information content is intertwined with the layout of the content, making their separation difficult, for example. Conversely, within XML a description of the storage layout and logical structure of content is maintained separate from the content itself. However, both XML and HTML are derivatives of a markup language known as Standard Generalized Markup Language (SGML). XML as referred to herein refers generally to any standard of XML, and specifically to XML 1.0, as described in the W3C recommendation REC-xml-19980210 dated Feb. 10, 1998, and also available on the web site http://www.w3.org.
HTTP, and hence XML in the context of HTTP, allows for client computers to access resources that exist on server computers. The term resource refers to any piece of information that has a location described by a Uniform Resource Locator (URL), which commonly can be expressed in the form HTTP:// less than domain greater than . less than extension greater than , where  less than domain greater than  specifies a particular domain, and  less than extension greater than  can be, for example, .com, .edu, and .net, among others. A resource can be, for example, a Web page, a hierarchical collection of information such as folders, a document, a database, a bitmap image, or a computational object. HTTP is a xe2x80x9cverb-basedxe2x80x9d protocol. Verbs operate on resources. HTTP/1.1 describes a small set of verbs (e.g., GET, POST, PUT) that enable clients to retrieve resources from servers and to put resources onto servers, but not to perform granular manipulations of the objects on the server. Recently, extensions to HTTP have been proposed that allow for more granular queries of resources. For example, using the recently proposed PROPFIND extension, a client may send a request to a server asking the server to return descriptive information about the resources contained on the server. The server""s response will contain a comprehensive summary of all of the resources contained within a specific hierarchy as well as specific property values associated with the resources. A property is specifically a name/value pair that contains descriptive information about a resource. More generally, a property is any information about a resource. An example of a property associated with a resource might be the xe2x80x9cauthorxe2x80x9d of the resource or the most recent xe2x80x9cdate of modificationxe2x80x9d of the resource. Other recently proposed extensions enable clients to send requests to servers instructing the server to delete properties of resources, create new collections of objects, move or copy objects, etc.
One set of extensions allowing for more granular queries of resources are generally referred to as the World-Wide-Web Distributed Authoring and Versioning (WebDAV) extensions to HTTP. The goal of WebDAV, broadly speaking, has been to add remote authoring capabilities to HTTP, so that HTTP can be more convenient as a readable and writable collaborative medium, and not necessarily only a browsing medium for web pages. WebDAV is generally described in the reference E. James Whitehead, Jr., World-Wide-Web Distributed Authoring and Versioning (WebDAV): An Introduction, in StandardView, Vol. 5, No. 1, March 1997, pages 3-8. The part of WEBDav that describes the setting and enumerating of properties is described in the reference Internet Engineering Task Force (IETF) Request for Comment (RFC) 2518, entitled HTTP Extensions for Distributed Authoring, by Y. Goland, E. Whitehead, A. Faizi, S. Carter and D. Jensen, and dated February 1999. More generally, this reference specifies a set of methods, headers and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, name space manipulation, and resource locking (also referred to as collision avoidance).
A limitation to these extensions that provide for more granular queries, primarily in the context of the PROPFIND command, is that the responses to the queries typically always provide root-level information, which may not be wanted. Root-level information refers to information regarding the immediate level of a hierarchical collection specified. For example, a hierarchy of folders may have three levels: a first level at the very top of the hierarchy including one folder, a middle level of the children folders of the top-level folder, and a bottom level of children folders of the middle level of folders. A request asking for properties of this hierarchical collection may specify a folder in the middle level, in which case the folder in this level is the root level of the request. Another request may ask for properties by specifying the folder at the top level, in which case this level is the root level of the request. When making such a request, information regarding the root level is always returned, even if it is unwanted. There is no manner by which to specify that such root-level information is not wanted to be returned within a request.
This means that a client receiving such information from a server must remove this information, which adds to the processing burden of the client, as well as to the processing burden of the server in generating this information. This latter burden can affect scalability of the server. Furthermore, transmission of this information across a network unduly clogs the bandwidth of the network, since the information itself is not used by the client but still is transmitted. For these and other reasons, there is a need for the present invention.
The invention provides for depth-related requests without root-level information or actions according to standard request-response protocols such as HTTP. For example, in one embodiment, a method specifies a request, such as a PROPFIND command, for application against a collection, such as a hierarchy of folders. Within a DEPTH header of the request, the method includes a NOROOT token to indicate that root-level information of the collection is unwanted, or to indicate that root-level action upon the collection is unwanted. (It is noted that headers can be optionally included in the request, and have semantic meanings that are defined by the protocol. The function of headers generally is to modify the nature of the request.) The request is then output, according to a predetermined transport protocol such as HTTP. In one embodiment, the outputting of the command is also according to a predetermined markup language, such as XML. By outputting the request, the method may send the request from a client to a server over a network such as the Internet, an intranet, or a network. A server can then respond to the client, and not provide the root-level information, since the client specifically requested that it did not want this information.
Embodiments of the invention therefore provide for advantages not found in the prior art. Computers coupled to TCP/IP-compliant networks such as the Internet, intranets, and extranets can generate depth-related requests of resources accessible on these types of networks, and specifically request that root-level information not be provided. For example, a client request may specify a DEPTH header with the NOROOT token against a hierarchical directory of folders beginning with the top-level folder to indicate that root-level information regarding the top-level folder need not be returned by the server responding to the request. Because Internet connectivity is becoming increasingly standard for computers, this means that that the invention provides for improved usefulness of the Internet as a readable and writable collaborative medium.
The invention also has advantages to shortcomings in the prior art not described in the background section. For example, the NOROOT extension is useful when a computer is attempting to perform a change operation on a hierarchy. If the client desires to MOVE all the resources in a collection to another collection, but not move the collection itself, this can only be accomplished in the prior art by issuing a separate MOVE request for each resource, which is inconvenient and time-consuming. However, under the invention, it is possible to issue a command only to the children of a collection, and not to the collection itselfxe2x80x94thus reducing the cost of the scenario to a single request. That is, as substantially described herein, the invention is described as applicable to situations where root-level information is not desired. However, the invention is also equally applicable to situations where root-level actions are not desired, as can be appreciated by those of ordinary skill within the art. The invention is inclusive both of the case where root-level information is not desired, as well as the case where root-level actions are not desired.
The invention includes computer-implemented methods, machine-readable media, computerized systems, and computers of varying scopes. Other aspects, embodiments and advantages of the invention, beyond those described here, will become apparent by reading the detailed description and with reference to the drawings.